The field of the invention is that of telecommunications and more particularly that of virtual private networks (VPN).
The context of the invention is that of a level 3 VPN consisting of core routers (P), access routers (PE), and client routers (CE), using the MPLS VPN technology defined in the Internet Engineering Task Force (IETF) document Request For Comments (RFC) 4364.
The MPLS VPN technology is not described here. For more information on this technology see the above document RFC 4364.
Some VPN communications services have high demands in terms of CE to CE availability (for example voice (VoIP) and telemedicine services). These services require deterministic rerouting within less than 100 milliseconds (ms) in the event of a failure affecting a link or a node. At present, the only technology providing such rerouting performance is the Fast Reroute technology that sets up in advance local back-up paths bypassing the protected element. In the event of a failure, the directly upstream node updates its routing table and switches the traffic to the back-up path. This method requires no route calculation or signaling after the failure. Moreover, the back-up routes are preinstalled in the switching tables of the routers, which guarantees a determinist rerouting time of less than 100 ms.
There are two protection modes:                the MPLS Fast Reroute mode based on setting up end-to-end MPLS-TE primary tunnels locally protected by MPLS-TE back-up tunnels, described in the IETF document RFC 4090;        the IP Fast Reroute mode based on protecting IP routes by back-up routes bypassing the protected element and with no risk of loop. These back-up routes can be in connected mode with local back-up MPLS-TE tunnels or in non-connected mode if there is no risk of loop. For more details of this second mode see the following documents:        Shen, Pan, “Nexthop Fast ReRoute for IP and MPLS” (http://www.potaroo.net/ietf/all-ids/draft-shen-nhop-fastreroute-01.txt); and        Shand, Bryant, “IP Fast Reroute Framework”, http:/www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-framework-05.txt.        
A tunnel is a virtual connection in which a packet conforming to a given protocol (e.g. IPv4, IPv6, MPLS, etc.) is placed in an external packet conforming to the same protocol or another protocol (e.g. IP, MPLS, etc.) to transport it from one point to another. In this tunnel mechanism, the network equipments situated between the entry point of the tunnel and its exit point process and are aware only of the external packet, not the internal packet.
With meshing of the PEs by MPLS-TE primary tunnels, the MPLS Fast Reroute mode protects PE-P and P-P links and P nodes. It is difficult to scale up because it requires meshing of all the PEs and therefore requires a number of tunnels proportional to the square of the number of PEs. It is therefore applicable in practice only to a small number of PEs (approximately 100).
The IP Fast Reroute mode protects CE-PE, PE-P, and P-P links and P nodes. It requires no MPLS-TE primary tunnels and is therefore more readily scaled up.
The current Fast Reroute techniques described above provide no protection for access routers of an MPLS-VPN network.
The MPLS Fast Reroute technique cannot protect the access routers because this would require starting up the MPLS-TE tunnels on the CEs.
At present there is no mechanism for implementing MPLS-TE between two client routers.
Moreover, even if such a mechanism were defined, it would have limitations in terms of scaling up because it would require a number of tunnels proportional to the square of the number of client routers, and would therefore in practice be applicable only to a very small number of client routers.
Moreover, the IP Fast Reroute technique provides no protection for access routers because, for the core router that triggers the Fast Reroute process, the destination is the access router, so that if the access router were to disappear there would no longer be a destination.
Moreover, even if the core router were advised of a back-up access router for backing up a nominal access router, the back-up access router could not process the VPN packets because it would not know the correct context for processing them.
The core router would switch the traffic from a nominal access router to a back-up access router without changing the VPN label (because it would not know it).
But, VPN labels are allocated locally by the access routers and have only a local meaning, and so the traffic would be routed to a bad VPN on the back-up access router.
Access routers are particularly sensitive, and have a high workload (maintaining and updating VPN tables); statistics show that they fail frequently.
The only back-up mechanisms against router access failure available at present rely on convergence of the Border Gateway Protocol (BGP), with back-up times exceeding one second, which is not compatible with the availability demands of real-time services.
To achieve good availability at the client router to client router level it is therefore crucial to define new mechanisms for quickly protecting access routers able to support a large number of client routers (i.e. scaling up).